Test levels
In practice, we generally see the following possibilities for the various test levels:
|
System test
|
·
Project manager from the
supplier
·
Project manager /project leader for
realisation
|
|
Functional acceptance test
|
·
Project manager from
client/accepters
·
Head of functional management
|
|
System integration test
|
·
Project manager from client
/accepters
·
Head of functional management
|
|
Users acceptance test
|
·
Project manager from client
/accepters
·
Head of users organization
|
|
Production acceptance test
|
·
Project manager from client
/accepters
·
Head of system management
|
Assignment
This would appear to be the obvious core of the activity – “Establishing the assignment”. Despite the importance,
in practice the formulation of the assignment is often somewhat abstract and generic, in terms of “providing a quality
assessment” or “providing insight into risks”. It is mainly in the scope, preconditions and assumptions (and later the
strategy) that the total assignment is sharply defined.
Iterations - Iterative or agile system development delivers a large number of (interim)
releases or prototypes for testing. It should be clear from the formulation of the assignment that such an interim
release or prototype may not be assessed on every aspect of a forthcoming production system, but only on those aspects
that are relevant to the interim release or prototype itself.
Payment types
Usually, the client makes resources (people and means) available, or pays for them, for example, by hiring in people
internally or externally. Payment usually takes place based on the number of hours. In certain cases, particularly in
the case of outsourcing, when the testing is done by an external supplier, more creative agreements can be made. Below
are some possible constructions that appear in practice:
-
Fixed-price - The supplier carries out the testing for a previously agreed fi xed price. This
usually includes a fixed number of retests. In the event of a breakdown in the test process owing to the client
being unable to meet the set agreements, or if more (re)tests are necessary than were agreed, additional charges
are applied. In the other cases, the risk is borne by the supplier.
-
Fixed-price per test case - A variant on the above is that a fixed sum is agreed per test case to be specified and
executed
-
Fixed-date - Similar to fixed-price, but with a fixed date of completion
-
Fixed-date, fixed-price - As above, with both a fi xed price and a date of completion
-
Bonus malus - In addition to the above, agreements can be made with the intent of distributing the
risk more satisfactorily among both parties. By doing this, the client pays the supplier by the hour with the
understanding that there is a fixed date or fixed price. If the supplier requires fewer hours or less lead time, he
is given a bonus in the form of more money. And an example of malus: if after X amount of time after going into
production, critical faults arise, or if the timeline or hours are exceeded, the supplier gives a discount on the
fees.
-
Result sharing - An unconventional form is when the supplier is paid with a percentage of the
profits from the new system. In this case, the system is an investment for both the client and the supplier, and
both have every interest in a successful outcome. It will be obvious that this involves big risks (but also
opportunities).
|
